Computer and Access Control Method in a Computer

ABSTRACT

A CPU  11  executes a management program B (Pb), from a management program A (Pa) receives authentication information, a request, and a program ID, and determines whether the authentication information is correct. If the authentication information is correct, the CPU  11  acquires the execution authority information of the authenticated user, compares the received program ID with the program ID including in the acquired execution authority information, and determines whether execution authority corresponding to the received program ID is defined. If the CPU  11  determines that execution authority corresponding to the received program ID is defined, it established the defined execution authority as the execution authority for the management program B (Pb).

CROSS-REFERENCE TO RELATED APPLICATION

This application relates to and claims priority from Japanese PatentApplication No. 2004-315583, filed on Oct. 29, 2004, the entiredisclosure of which is incorporated by reference.

BACKGROUND

This invention relates to a computer that executes processes requestedinteractively by a multiplicity of programs, and to an access controlmethod for a multiplicity of interacting programs.

A storage system (storage array device) comprises independent storagemanagement programs, with various processes requested by users beingexecuted on the storage device via the storage management programs. Whena storage system is to be operated in an integrated fashion, anintegrated management program that carries out overall management of thestorage management programs on the storage device is installed. Theintegrated management program invokes the relevant storage managementprogram and executes a process requested by a user via the invoked upstorage management program.

In an environment in which a plurality of storage systems areintegrated, a given resource of a storage system can be accessed eitherdirectly via an individual storage management program, or indirectly viaan integrated management program that calls up the relevant storagemanagement program. In this instance, if the status of a storage systemresource is modified directly by an individual storage managementprogram, a discrepancy with the resource status retained by theintegrated management program may occur. Additionally, if the status ofa given resource of a storage system is modified simultaneously by amultiplicity of storage management programs, discrepancies may ariseamong resource status retained by the different storage managementprograms.

This had been addressed in the past by means of operation to preventmodification of resources by storage management programs that a client(user) directly uses storage management programs, or by making privatethe accounts of storage management programs whose use is to berestricted, with only an integrated management program retainedinternally. Various other technologies for limiting user authority inconsideration of interaction among programs are known as well.

SUMMARY

However, a problem with an approach involving operation to preventmodification of a resource by storage management programs that a client(user) directly uses is that as long as there is a user who does notcomply with the operation, the desired effect cannot be achieved. Also,where accounts of storage management programs whose use is to berestricted are made private with only an integrated management programretained internally, it becomes necessary to create a private accountfor each user or each authority, creating the problem of increasedmanagement costs. Further, with technologies that limit user authority,interaction of programs is not taken into consideration, so that it isnot possible to solve the aforementioned problems in environments wherea plurality of storage systems are integrated.

With the foregoing in view, there is need to provide, in a computer thatexecutes processes requested by interaction of a plurality of programs,a way to determine authority to execute for programs depending on theprogram usage mode.

The invention addresses the problem by providing a computer thatexecutes processes requested by interaction of a plurality of programs.The computer pertaining to the present invention comprises a receivingmodule that requests a process and acquires authenticating information;an invoking program executing module that invokes a program executingmodule for executing a process corresponding to said acquired request,said invoking program executing module sending to the invoked programexecuting module identifying information for identifying said invokingprogram executing module and said acquired authenticating information;and an invoked program executing module that by being invoked by saidinvoking program executing module, or by directly receiving a request,executes the requested process, said invoked program executing modulehaving an authenticating module that uses said authenticatinginformation and the identifying information of said invoking programexecuting module to establish authority to execute for said invokedprogram executing module.

According to the computer pertaining to the invention, identifyinginformation for identifying the invoking program executing module andacquired authenticating information are sent to the invoking programexecuting module, whereupon the authenticating information and theinvoking program executing module identifying information are used toestablish authority to execute for said invoked program executingmodule, whereby in a computer that executes processes requestedinteractively by a multiplicity of programs, authority to execute forprograms can be determined according to program usage mode.

The computer pertaining to the present invention can also be reduced topractice as an access control method, an access control program, and acomputer-readable recording medium having an access control programrecorded thereon.

The following description of the computer and access control methodwhich pertain to the invention is made on the basis of embodiments, withreference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified illustration of the computer system pertaining toFirst Embodiment.

FIG. 2 is an illustration of modules stored in the memory of thecomputer in First embodiment.

FIG. 3 is an illustration of functional blocks realized by theadministration computer pertaining to First embodiment.

FIG. 4 is an illustration of an exemplary user management table inmanagement program B.

FIG. 5 is an illustration of an exemplary authority to executedefinition table defining executable operations by means of definedauthority to execute.

FIG. 6 is an illustration of an exemplary operation definition tablethat defines content of executable operations by means of definedoperations.

FIG. 7 is a flowchart showing the processing routine executed bymanagement program A (invoking program).

FIG. 8 is a flowchart showing the processing routine executed bymanagement program B (invoked program).

FIG. 9 is a simplified illustration of a computer system.

FIG. 10 is a flowchart showing the processing routine executed in theevent that management program B is executed from a client computer viamanagement program A.

FIG. 11 is a flowchart showing the processing routine executed in theevent that management program B is executed directly from a clientcomputer.

FIG. 12 is a simplified illustration of the computer system pertainingto Second Embodiment.

FIG. 13 is an illustration of functional blocks realized by theadministration computer pertaining to Second embodiment.

FIG. 14 is an illustration of an exemplary user management table usedfor establishing authority to execute in management program B when fourmanagement programs interact and execute management of the storagedevice 20.

FIG. 15 is an illustration of an exemplary authentication informationmanagement table for managing authentication information.

FIG. 16 is an illustration of an exemplary program informationmanagement table for administering program information.

DESCRIPTION OF THE PREFERRED EMBODIMENTS First Embodiment SystemConfiguration:

The following description of the computer system pertaining to Firstembodiment makes reference to FIG. 1 and FIG. 2. FIG. 1 is a simplifiedillustration of the computer system pertaining to First embodiment. FIG.2 is an illustration of modules stored in the memory of the computer inFirst embodiment.

The computer 10 in First embodiment is an administration computer(administration server computer) that manages a storage device, forexample, carrying out creation of volumes in the storage derive,assigning a host, and setting zoning and LUN masking; it is connected toone or a plurality of storage devices 20 and to a network 40. Thenetwork 40 is a local area network (LAN) with Ethernet (registeredtrademark) architecture, that carries out transmission of data using theTCP/IP communications protocol. Client computers 30, 31, 32 areconnected to the network 40; the client computers 30 to 32 executemanagement of the storage device 20 via the administration computer 10.

A service host computer 50 is connected to the network 40, and theservice host computer 50 is connected to the storage device 20 via a SAN(Storage Area Network) 41. The service host computer 50 executes adatabase management system (DBMS) or other service program in responseto requests from the client computers 30 to 32, and writes processresults to the storage device 20, or utilizes an information resourcestored in the storage device 20. A Fibre Channel or iSCSI communicationsprotocol is used in the SAN.

The computer 10 comprises a CPU 11, a memory 12, a rear end I/Ointerface 13, and a front end I/O interface 14. The CPU 11, the memory12, the rear end I/O interface 13, and the front end I/O interface 14are interconnected via a bus. The CPU 11 is a processing unit thatexecutes various programs and modules stored in the memory 12. Thememory 12 is a so-called internal storage device, and includes bothnonvolatile memory storing the various modules etc., and volatile memoryfor temporary storage of operation results. The rear end I/O interface13 is connected to the storage device 20 via a local area network (LAN).The front end I/O interface 14 is connected to the network 40, andexecutes sending and receiving of commands and data among the clientcomputers 30 to 32 using the TCP/IP protocol.

The storage device 20 comprises a disk array controller 21, a cache 22,a plurality of disk devices 23, and an I/O interface 24. The disk arraycontroller 21 is a control circuit that executes control processes ofvarious kinds on the storage device 20, and comprises a CPU 211, memory212, and an I/O port. The cache 22 is a kind of memory device fortemporary storage of data that is to be written to a disk device 23, orof data being read from a disk device 23.

The disk devices 23 are provided as a disk array device of RAIDconfiguration composed of a plurality of magnetic hard disk drives, theplurality of magnetic hard disk drives constituting one or severallogical units (LU), or as a single hard disk drive have one or severalmemory areas, i.e. logical units (LU). Access to each logical unit iscarried out using a logical unit number (LUN) and a logical blockaddress (LBA). The I/O interface 24 is connected to the rear I/Ointerface 13 of the administration computer 10 via a signal line.

The client computers 30 to 32 are, for example, terminal devices forinput or output of data of various kinds, and via the service hostcomputer 50 execute, for example, database management processes, andexecute writing of processed data to the storage device 20 and readingof data from the storage device 20. The client computers 30 to 32 alsocarry out management of the storage device 20 via the administrationcomputer 10. The client computers 30 to 32 may instead be a singlecomputer, or four or more.

The following description of the various programs and modules stored inthe memory 12 makes reference to FIG. 1 and FIG. 2. The memory 12 hasstored therein a send/receive process program Pr1 for exchange of dataand requests with the client computers, a management program A (Pa), amanagement program B (Pb), a management program C, and user informationutilized by each of the management programs, stored in association withthe respective management programs. By way of example, FIG. 2 shows themanagement program A (Pa) and the details of the user information Uiautilized by the management program A (Pa).

The management program A (Pa) is an integrated storage managementprogram that handles in an integrated manner the management program B(Pb) and C (Pc) provided to each of the storage devices 20, andcorresponds to the invoking (first) program. With the management programA (Pa), there are carried out processes that span several storagedevices, and that cannot be managed by the individual managementprograms B (Pb) and C (Pc) provided to each of the storage devices 20.For example, the management program A (Pa) provides a storage poolfunction whereby a number of storage devices are managed as a singlevirtual storage device, backup schedule management of the logicalvolumes (logical units) of a storage device, and restriction managementof access to the logical volumes.

The management program A (Pa) comprises a request receiving module Ma1that receives requests and authentication information from the clientcomputer 30; an authentication information acquiring module Ma2 thatacquires the received authentication information; a user authenticationmodule Ma3 that carries out user authentication using authenticationinformation; an execution authority establishing module Ma4 that uses aprogram ID to establish authority to execute for an invoked program; arequest executing module Ma5 that executes requests input from theclient computer 30; and an external program invoking module Ma6 thatexecutes identification of an invoked program and invocation of theinvoked program.

The user information Uia comprises a user management table Uia1, anexecution authority definition table Uia2, and an operation definitiontable Uia3, described later.

The management programs B (Pb) and C (Pc) likewise comprise similarmodules. The management programs B (Pb) and C (Pc) are assigned on aone-to-one basis to any single storage device, and execute variousmanagement processes in the corresponding storage device. The managementprograms B (Pb) and C (Pc) provided to the individual storage devicescorrespond to invoked (second) programs. The CPU 11 corresponds to theinvoked program executing module and the invoking program executingmodule. Alternatively, by viewing the management programs A (Pa), B (Pb)and C (Pc) executed by the CPU 11 as management program executingmodules A (Pa), B (Pb) and C (Pc), the management program A executingmodule Pa can be considered as the invoking program executing module,and the management program B, C executing modules Pb, Pc as invokedprogram executing modules.

Typically, since the management programs B (Pb) and C into theadministration computer 10 are sequentially introduced each time that anadditional storage device 20 is provided, the individual storage devices20 a managed by the individual management programs, and thus it is notpossible to manage a plurality of storage devices 20 in a consolidated(integrated) manner. Under such conditions, by introducing theIntegrated management program A (Pa) into the administration computer10, consolidated management of the storage devices is possible throughthe Integrated management program A (Pa).

The following description of the access control process executed duringprogram interactive process in the administration computer 10 makesreference to FIG. 3 to FIG. 8. FIG. 3 is an illustration of functionalblocks realized by the administration computer pertaining to Firstembodiment. FIG. 4 is an illustration of an exemplary user managementtable in the management program B (Pb). FIG. 5 is an illustration of anexemplary authority to execute definition table defining executableoperations by means of defined authority to execute. FIG. 6 is anillustration of an exemplary operation definition table that definescontent of executable operations by means of defined operations. FIG. 7is a flowchart showing the processing routine executed by the managementprogram A (Pa) (invoking program). FIG. 8 is a flowchart showing theprocessing routine executed by the management program B (Pb) (invokedprogram). The programs and modules are executed by the CPU 11.

The processing routine shown in FIG. 7 is initiated, for example, byrunning the management program A (Pa) from the client computer 30. TheCPU 11 executes the request receiving module Ma1, and receives theauthentication information and process request input from the clientcomputer 30. Authentication information consists of account informationnecessary for authentication, for example, a user name and password; theprocess request is, for example, a request to create a new logicalvolume in the storage device 20.

The CPU 11 then executes the authentication information acquiring moduleMa2 and acquires the received authentication information. The CPU 11executes the authentication module Ma3 and executes authentication forthe management program A (Pa) (Step S100). Specifically, the CPU 11searches the user information and determines whether authenticationinformation exists for the management program A (Pa) in question. In theevent that authentication information can be verified to exist, i.e.authentication is successful (Step S100: Yes), the CPU 11 runs theexecution authority establishing module Ma4. If on the other handauthentication information cannot be verified to exist, i.e.authentication is not successful (Step S100: No), the client computer 30is informed to the effect that authentication failed, and the processingroutine terminates.

The CPU 11 executes the execution authority establishing module Ma4, andon the basis of the user management table establishes in the managementprogram A (Pa) authority to execute assigned to the user. For example,the authority to invoke the management program B (Pb) via the managementprogram A (Pa), the authority to modify settings in the managementprogram A (Pa), or authority settings denying either or both of theseare established.

The CPU 11 executes the request executing module Ma5, and depending onthe established authority to execute, executes the request input fromthe client computer 30. In the event that the request input from theclient computer 30 invokes the management program B (Pb), and authorityto invoke the management program B (Pb) via the management program A(Pa) is verified, the CPU 11 executes the external program invokingmodule Ma6.

The CPU 11 identifies the invoked program that is to be invoked by therequest from the client computer 30 (Step S110). Specifically, inassociation with the request input from the client computer 30, there isidentified the storage device 20 constituting the target to which accessis being requested and which is targeted for execution of the processrequested by the LUN, and thus the management program managing theidentified storage device 20, namely, the management program B (Pb) inthis embodiment, can be identified. The CPU 11 also determines whetherthe authentication information input from the client computer 30 is usedin common by the invoking management program and the invoked managementprogram (Step S120). For example, it can be determined whether theinvoked management program is integrated with the invoking managementprogram.

When the management program A (Pa) and management program B (Pb) areintegrated, a single set of authentication information is shared incommon by the management program A (Pa) and management program B (Pb).On the other hand, when the management program A (Pa) and managementprogram B (Pb) are not integrated, individual identifying informationwill be required for each, and it will therefore be necessary to convertto authentication information corresponding to the management program B(Pb). Conversion is carried out, for example, using a table thatassociates authentication information in the management program A (Pa)with authentication information in the management program B (Pb) for agiven user, as the user information of the management program A (Pa).

If authentication information is shared in common (Step S120: Yes), theCPU 11 acquires the authentication information input from the clientcomputer 30 (Step S130), as authentication information that is valid inthe invoked program.

If authentication information is shared in common (Step S120: No), theCPU 11 converts the authentication information input from the clientcomputer 30 into authentication information that is valid in the invokedprogram (Step S140).

The CPU 11 invokes the management program B (Pb), and sends the acquiredor converted authentication information and the request, and identifyinginformation for identifying the management program A (Pa) (program ID)to the management program B (Pb) (Step S150), and then terminates theroutine. As the program ID, there is used at least one item ofinformation such as program name, program product ID, folderconfiguration (e.g. a file indicating the version), registry key.

Through invocation from the management program A (Pa), the managementprogram B (Pb) initiates the processing routine shown in FIG. 8. The CPU11 executes the request receiving module Mb1, and receives theauthentication information and process request, and the program ID, sentfrom the management program A (Pa) (Step S200). The CPU 11 executes theauthentication information acquiring module Mb2, acquires the receivedauthentication information, executes the user authentication module Mb3,and determines whether the authentication information is correct (StepS210). Specifically, the CPU 11 searches the user information andsearches for whether the corresponding authentication informationexists.

The user management table shown in FIG. 4 may be employed as userinformation, for example. That is, the user information includes a userID for identifying the user, and a password for determining (verifying)whether the user ID has been input by the proper user. If the CPU 11determines that the authentication information is not correct, i.e. thatthere is no corresponding authentication information (Step S210: No),the CPU 11 suspends the process, returns an Authentication Failed statusto the client computer 30 (Step S220), and terminates the processingroutine.

If the CPU 11 determines that the authentication information is correct,i.e. that corresponding authentication information exists (Step S210:Yes), CPU 11 runs the execution authority establishing module Mb4. TheCPU 11 acquires authority to execute information (the user managementtable) for the authenticated user (Step S230), compares the receivedprogram ID with the program ID included in the acquired authority toexecute information (Step S240), and determines whether authority toexecute corresponding to the received program ID are defined (StepS250). As noted, as the program ID, for example, there is used programname, program product ID, folder configuration (e.g. a file indicatingthe version), registry key, and thus information enabling the programIDs to be compared and authenticated is stored by way of userinformation of the management program B (Pb).

Specifically, using the user management table shown in FIG. 4, it isdetermined whether a program ID corresponding to the received program IDexists in the user management table. As the method for making thedetermination, it is acceptable to always assign some authority toexecute to program IDs described in the user management table, and todetermine whether a program ID corresponding to the received program IDexists in the user management table. Alternatively, it would beacceptable to describe all related program IDs in the user managementtable and to assign detailed authority to execute to each program ID,and make the determination on the basis of the authority to executeassigned to a particular program ID.

If the CPU 11 determines that authority to execute have been defined forthe received program ID (Step S250: Yes), the defined authority toexecute are established as authority to execute for the managementprogram B (Pb) (Step S260). On the other hand, if the CPU 11 determinesthat authority to execute have not been defined for the received programID (Step S250: No), the CPU 11 suspends the process, returns anAuthentication Failed status to the client computer 30 (Step S220), andterminates the processing routine.

In the example of FIG. 4, in the event that Program A (Pa) is input asthe program ID, “Administrator” authority to execute are established,whereas in the event that no program ID is input, i.e. where themanagement program B (Pb) has been run directly by the client computer30, “User” authority to execute are established. Generally,“Administrator” authority to execute are those intended to be assignedto the administrator, and that grant all authority to execute withrespect to the management programs. On the other hand, “User” authorityto execute are those intended to be assigned to ordinary users, and thatgrant only certain authority to execute with respect to the managementprograms.

As shown in FIG. 5, in the embodiment, the “Administrator” is grantedall system operation settings, resource operations, and resourcereference operations, whereas a “User” on the other hand is granted onlyresource reference operations. As shown in FIG. 6, system operationsettings permit carrying out of system settings, which are settings foroperating programs, including host name, host number, and other serversettings; resource operations include both resource modifications, i.e.creating, modifying, and deleting logical units, as well as resourcereference, whereas resource reference operations permit only resourcereference.

The CPU 11 executes the request executing module Mb5, and depending onthe established authority to execute, executes the request input fromthe client computer 30 (Step S270), and terminates the processingroutine. In the event that an additional management program C is invokedvia the management program B (Pb), an external program invoking moduleMb6 may be provided for the purpose of invoking the management programC.

The following detailed description of the access control process duringthe program interaction process in First embodiment makes reference toFIG. 9 to FIG. 11. FIG. 9 is a simplified illustration of the computersystem. FIG. 10 is a flowchart showing the processing routine executedin the event that the management program B (Pb) is executed from aclient computer via the management program A (Pa). FIG. 11 is aflowchart showing the processing routine executed in the event that themanagement program B (Pb) is executed directly from a client computer.

To briefly describe the arrangement of the computer system, the computersystem comprises a client computer 30, an administration computer 10,and first and second storage devices 201, 202. On the client computer 30are stored an integrated management client program 31 that executes astorage integrated operation management program Pa (invoking program)stored on computer 10; and first and second individual management clientprograms 32, 33 for executing first and second storage device managementprograms Pb, Pc (invoked programs). The CPU provided in the clientcomputer 30 functions as the client program executing module thatexecutes these client programs.

On computer 10 are stored first and second storage device managementprograms Pb1, Pc1 for executing management of the first and secondstorage devices 201, 202; and a storage integrated operation managementprogram Pa1 for integrated management of the first and second storagedevice management programs Pb, Pc. The storage integrated operationmanagement program Pa1 comprises an authentication module Mpa1 thatcarries out user authentication, a storage operation module Mpa2 thatcarries out operations on the storage devices, a storage operationinformation managing module Mpa3 that manages information for storageoperation, and a user information storage module Mpa4 that stores userinformation including authentication information needed forauthentication. In the storage operation information management moduleMpa3 are stored device information relating to resource status/operatingstatus of the first and second storage devices 201, 202; systemconfiguration information for the host and service server; and operationpolicies including backup schedule, countermeasures in the event amalfunction occurs, and security policy.

The first and second storage device management programs Phi, Pc1 eachcomprise an authentication module Mpb1, Mpc1 that carries out userauthentication; a storage operation module Mpb2, Mpb3 that carries outoperations on the storage device 201, 202; and a user informationstorage module Mpb3, Mpc3 that stores user information includingauthentication information needed for authentication.

The first and second storage devices 201, 202 are each configured as aRAID composed of several disk devices, and have one or several logicalunits (LU).

The following description of execution of the management program B (Pb)from the client computer via the management program A (the storageintegrated operation management program Pa1) makes reference to FIG. 10.

The user 1 inputs to the client computer 30 authentication informationfor logging in to the management program A (Pa1), and a new volumecreation request to the first storage device 201 (Step U1). Theintegrated management client program 31 of the client computer 30 sendsthe input authentication information and volume creation request to themanagement program A (Pa1) (Step C1). The administration computer 10(CPU) executes the management program A (Pa1), and performs userauthentication by means of the authentication module Mpa1 (Step PaS1).In the event that user authentication is successful, the administrationcomputer 10, by means of the storage operation information managementmodule Mpa3, runs the management program that manages the target storagedevice, for example, the management program B (Pb1), and sends to themanagement program B (Pb1) authentication information for the managementprogram B (Pb1) and identifying information (program ID) for themanagement program A (Pa1) (Step PaS2). In the event that userauthentication fails, the administration computer 10 notifies the clientcomputer 30 of authentication failure, so that the user 1 can benotified of the authentication failure to the management program A(Pa1), for example, by means of the display screen of the administrationcomputer 10.

The administration computer 10 executes the management program B (Pb1),and using the authentication information for the management program B(Pb1) and the ID of the management program A (Pa1), performs userauthentication by means of the authentication module Mpb1 (Step PbS1);in the event that authentication fails (Step PbS2: No), it notifies themanagement program A (Pa1) of the authentication failure. Upon receivingnotification of authentication failure, the management program A (Pa1)sends an Authentication Failed notification to the client computer 30(Step PaS3). The user 1 can be notified of the authentication failure tothe management program B (Pb1), for example, by means of the displayscreen of the client computer 30.

In the event that authentication to the management program B (Pb1) issuccessful (Step PbS2: Yes), the administration computer 10 establishesthe user authority to execute assigned to the user 1 as authority toexecute having a “resource modification authority” (Step PbS3). Theadministration computer 10 executes the storage operation module Mpb2and requests the first storage device 201 to create the volume. Uponreceiving the volume creation request, the first storage device 201creates the requested volume, for example, via a disk adapter (StepSS1). When the volume creation process is complete, the first storagedevice 201 sends Volume Created notification to the management program B(Pb1) (Step SS2).

The management program B (Pb 1) notifies the management program A (Pa1)to the effect that the volume has been successfully created (Step PbS4).The management program A (Pa1) stores information for the newly createdvolume as device information in the storage operation informationmanagement module Mpa3, and requests the client computer 30 to display asuccessful volume creation display screen (Step PaS4). By confirming thesuccessful volume creation display displayed on the display screen ofthe client computer 30, the user 1 can be notified of successfulcreation of a new volume in the first storage device 201.

The following description of direct execution of the first storagedevice the management program Pb (the management program B) by a clientcomputer makes reference to FIG. 11.

The user 1 inputs to the client computer 30 authentication informationfor logging in to the management program B (Pb1), and a new volumecreation request to the first storage device 201 (Step U10). The firstindividual management client program 32 of the client computer 30 sendsthe input authentication information and volume creation request to themanagement program B (Pb1) (Step C10). The administration computer 10executes the management program B (Pb1), and performs userauthentication by means of the authentication module Mpb1 (Step PbS10)using the authentication information of the management program B (Pb1).In the event that user authentication fails (Step PbS11: No), the clientcomputer 30 is notified of the authentication failure. The clientcomputer 30 displays the authentication failure on the display screen,so that the user 1 can be notified of the authentication failure withrespect to the management program B (Pb1), through the display screen ofthe client computer 30.

In the event that authentication with respect to the management programB (Pb1) is successful (Step PbS11: Yes), the administration computer 10establishes the user authority to execute assigned to the user 1 asauthority to execute having a “resource reference authority” (StepPbS12). Specifically, since there is no program ID (identifyinginformation) of the management program A (Pa1), a high authority levelenabling modification of resource status is not established. Since theuser 1 is only granted resource reference authority, the administrationcomputer 10 notifies the client computer 30 that the user 1 does nothave volume creation authority (Step PaS13). Through the display screenof the client computer 30, the user 1 can be notified that volumecreation is not allowed.

As described hereinabove, according to the administration computer 10 ofFirst embodiment, in cases where a multiplicity of the managementprograms interact, the desired access control can be carried outdepending on the mode of program interaction (the program startup mode,invoking mode). More specifically, in cases where a storage device ismanaged by means of an invoking program (storage integrated operationmanagement program Pa, Pa1) invoking an invoked program (storage devicemanagement program Pb, Pb1, Pc1), high authority to execute can beassigned to the user, whereas in cases where management of a storagedevice is executed directly by means of an invoked program, lowauthority to execute can be assigned to the user. That is, authority toexecute can be established in such a way that where an invoked programis executed through an invoking program, resource modification to thestorage device 20 and modification of system settings can be permitted,while in the case of direct execution by an invoked program, onlyreference to resources of the storage device 20 is permitted.

As a result, it is possible to avoid a situation in which, for example,in the event the storage device management program Pb has been rundirectly, and a resource of the storage device 20 has been modified, thestorage integrated operation management program Pa fails to be notifiedof the resource modification, so that execution of the storageintegrated operation management program Pa is impaired. Specifically, inthe event that the storage device management program Pb has been rundirectly, and a volume targeted in the backup schedule by the storageintegrated operation management program Pa has been deleted, if thestorage integrated operation management program Pa is not notified ofthe fact that the volume targeted in the backup schedule has beendeleted, an error will occur when the backup process is executed. Or,where the storage device management program Pb has been run directly,and the access address for a volume has been changed, the problem ofinability of the storage integrated operation management program Pa toaccess the desired address will occur.

With the administration computer 10 of First embodiment, on the otherhand, in the event that the storage device management program Pb hasbeen run via the storage integrated operation management program Pa,resource modifications to the storage device 20 will be permitted, butin the event that the storage device management program Pb has been rundirectly, resource modifications to the storage device 20 will not bepermitted, thereby reducing or avoiding the occurrence of the problemmentioned above.

In the authentication process carried out in an invoked program,identifying information of the invoking program is utilized, so that itis possible to quickly and accurately determine whether an invokedprogram has been executed through the agency of the invoking program, orwhether an invoked program has been executed directly. Additionally,establishment of authority to execute over a wide range depending on theinvoking program is possible as well.

Authority to execute may be granted as in the following examples aswell.

(a) When authority to execute of an invoked program is the same ascompared to the case where there is no program ID.

In cases where there is no effect on the invoking program even if aninvoked program is executed directly (in the case that there is noeffect on the processes of the invoking program), the accessrestrictions of the invoked program may be the same, regardless of theroute by which the invoked program is invoked.

(b) When low authority to execute is established for an invoked programas compared to the case where there is no program ID.

In the case of an unregistered program or a program ID that is no longersupported, running from the program will not be permitted even if theprogram ID is successfully acquired.

(c) When unique restrictions are imparted during program interaction.

Where the invoking program is a monitoring program, in the event ofrunning from the invoking program, reference authority will not begranted without exception.

Second Embodiment

The following description of the computer system pertaining to Secondembodiment makes reference to FIG. 12 and FIG. 13. FIG. 12 is asimplified illustration of the computer system pertaining to Secondembodiment. FIG. 13 is an illustration of functional blocks realized bythe administration computer pertaining to Second embodiment. Theadministration computer 100 pertaining to Second embodiment has a basicarrangement similar to the administration computer 10 pertaining toFirst embodiment, with the exception of a different arrangement of themodules stored in the management programs; since the arrangement of thestorage device in Second embodiment is similar to the arrangement of thestorage device 20 in First embodiment, symbols identical to the symbolsused in First embodiment are used, and detailed description ofarrangements is not provided.

In the computer system pertaining to Second embodiment, apart from theadministration computer 100, there is additionally provided anauthentication computer 60, with authentication processes for themanagement programs Pa2, Pb2 being executed in the authenticationcomputer 60. The authentication computer 60 comprises a CPU 61 forexecuting authentication processes; a cache 62 for temporary storage ofauthentication information used for authentication, or authenticationresults; memory 63 for storing an authentication program Pd and userinformation Uid; and an I/O interface 64 that executes communicationwith the administration computer 100 and the client computers 30, 31, 32via the local area network 40.

In this embodiment, since a separate authentication computer 60 isprovided in addition to the administration computer 100, as shown inFIG. 13, the management program A (Pa2) and management program B (Pb2)are not provided with the modules needed for user authentication.Instead, the authentication program Pd of the authentication computer 60comprises a sending/receiving module ML1 that sends and receivesauthentication information and authentication results to and from themanagement programs in the administration computer 100, anauthentication information acquiring module ML2 that acquiresauthentication information from received authentication information, auser authentication module ML3 that executes user authentication, anexecution authority establishing module ML4 that establishes authorityto execute depending on the order of program execution, and userinformation Uid.

Following is a description of the access control process during programinteraction in the computer system pertaining to Second embodiment.

When, for example, the management program A (Pa2) is run from the clientcomputer 30, the CPU 11 executes the request receiving module Ma1, andreceives the authentication information and process request input fromthe client computer 30. Authentication information consists of accountinformation necessary for authentication, for example, a user name andpassword; the process request is, for example, a request to create a newlogical volume in the storage device 20. The CPU 11 executes theauthentication information acquiring module Ma2, acquires the receivedauthentication information, and sends to the authentication computer 60authentication information for the acquired the management program A(Pa2).

In the authentication computer 60, the CPU 61 executes thesending/receiving module ML1, and receives identifying information sentfrom the management program A (Pa2). The CPU 61 executes theauthentication information acquiring module ML2 and acquires thereceived authentication information. The CPU 61 executes the userauthentication module ML3, and executes authentication with respect tothe management program A (Pa2). Specifically, the CPU 61 searches theuser information and determines whether authentication informationexists for the management program A (Pa2) in question. In the event thatauthentication is successful, the CPU 61 runs the execution authorityestablishing module ML4. If on the other hand authentication is notsuccessful the CPU 61 informs the client computer 30 via the managementprogram A to the effect that authentication failed.

When the CPU 61 executes the execution authority establishing moduleML4, on the basis of the user management table, authority to executeassigned to the user are established in the management program A (Pa2).For example, the authority to invoke the management program B (Pb2) viathe management program A (Pa2), the authority to modify settings in themanagement program A (Pa2), or authority settings denying either or bothof these are established, The CPU 61 sends the established authority toexecute to the request executing module Ma5 of the management program A(Pa2) via the sending/receiving module ML1.

The CPU 11 executes the request executing module Ma5, and depending onthe established authority to execute, executes the request input fromthe client computer 30. In the event that the request input from theclient computer 30 invokes the management program B (Pb2), and authorityto invoke the management program B (Pb2) via the management program A(Pa2) is verified, the CPU 11 executes the external program invokingmodule Ma6.

The CPU 11, by means of the request from the client computer 30,identifies the invoked program to be invoked, as described in Firstembodiment. The CPU 11 invokes the identified invoked program, forexample, the management program B (Pb2), and requests the invokedprogram to send authentication information and program identifyinginformation (program ID) of the management program A (Pa2).

The management program B (Pb2) is run by means of being invoked by themanagement program A (Pa2). The CPU 11 executes the request receivingmodule Mb1, and receives the authentication information and processrequest, and the program ID, sent from the management program A (Pa)(Step S200). The CPU 11 executes the authentication informationacquiring module Mb2, acquires the received authentication information,and sends the authentication information for the acquired the managementprogram B (Pb2) to the authentication computer 60.

In the authentication computer 60, the CPU 61 executes thesending/receiving module ML1, and receives identifying information sendfrom the management program B (Pb2). The CPU 61 executes theauthentication information acquiring module ML3 and acquires thereceived authentication information. The CPU 61 executes the userauthentication module ML3 and executes authentication with respect tothe management program B (Pb2). Specifically, the CPU 61 searches theuser information and determines whether authentication informationexists for the management program B (Pb2) in question. In the event thatuser authentication is successful, the CPU 61 runs the executionauthority establishing module ML4. On the other hand, in the event thatauthentication is not successful, the CPU 61 notifies the clientcomputer 30 of the authentication failure via the management program B(Pb2).

When the CPU 61 executes the execution authority establishing moduleML4, authority to execute assigned to the user are established, usingthe program ID. In this embodiment, as in First embodiment, where theprogram ID of the management program A (Pa2) is received together withauthentication information, authority to execute that permitmodification of resources in the storage device 20 are established.

On the other hand, when the management program B (Pb2) is run directlyfrom the client computer 30, only authentication information is sent tothe authentication computer 60, with no program ID being sent, so thereare established authority to execute that allow only reference ofresources in the storage device 20. That is, since the program ID isidentifying information that is given to the invoked program by theinvoking program, it cannot be utilized in cases where the invokedprogram is run directly.

The CPU 61 sends the established authority to execute to the requestexecuting module Mb5 of the management program B (Pb2) via thesending/receiving module ML1. In the management program B (Pb2) therehas been prepared an operation definition table that defines thecontents of operating processes that can be executed in association withauthority to execute.

The CPU 11 that has received the established authority to executeexecutes the request executing module Mb5, refers to the operationdefinition table and determines those operation processes that will bepermitted for the established authority to execute, and executes therequest input from the client computer 30. In the event that themanagement program B (Pb2) has been run directly by the client computer30, even if the request input from the client computer 30 is one tomodify a resource in the storage device 20, since only resourcereference operation processes are authorized, the request will not beexecuted. If on the other hand the management program B (Pb2) has beenrun via the management program A (Pa2), the requested resourcemodification process will be executed.

As described hereinabove, according to the computer system of Secondembodiment, in addition to the advantages afforded by the computersystem (administration computer) pertaining to First embodiment, thefact that an authentication computer 60 separate from the administrationcomputer 10 is provided can also reduce the load on the administrationcomputer 10. That is, since authentication processes for the managementprograms can be executed in the authentication computer 60, there is noneed to provided the administration computer 10 with the modules neededfor authentication processes, nor is there any need to assign computingresources for executing authentication processes.

Additionally, since user information required for authentication can bemanaged in consolidated fashion in the authentication computer 60,management and updating of authentication information can be madeeasier.

Other Embodiments

(1) Whereas in Embodiments 1 and 2 there were described examples ofinteraction of two management programs, authority to execute for thestorage device 20 could be used selectively in the same manner wherethree or more the management programs interact. Such a situation couldbe accommodated, for example, by providing the user management tableshown in FIG. 14. FIG. 14 is an illustration of an exemplary usermanagement table used for establishing authority to execute in themanagement program B when four management programs interact and executemanagement of the storage device 20.

In a case where three or more management programs interact, bydetermining the route by which a program is run, authority to executecan be established depending on the management program executed prior toexecution of the management program B. Also, where time information,i.e. order information can be appended to the program ID, authority toexecute can be established depending on the order in which managementprograms are run prior to execution of the management program B.Specifically, where for example the management program B interacts withexternal program C, and the management program B has acquired a programID from another program (Program A, for example), order information,after appending a comma to the end of the program ID by the externalprogram invoking module of the management program Pb, order informationis generated by linking the program ID of the management program B. Theorder information generated in this manner is sent to Program C.Management of the program ID acquired by the management program B isstored in memory in a predetermined field in the management program B;the external program invoking module refers to the field, and in theevent that a program ID is present, executes the process mentionedabove, or if not present, sends only the program ID of the managementprogram B to Program C. In this case, authority to execute can beestablished with a higher level of detail, depending on the executionenvironment of the management program.

(2) Whereas in Embodiments 1 and 2 authentication information andprogram IDs are managed by a single management table, namely, the usermanagement table, authentication information and program IDs couldinstead managed by several management tables. An example is shown inFIG. 15 and FIG. 16. FIG. 15 is an illustration of an exemplaryauthentication information management table for managing authenticationinformation. FIG. 16 is an illustration of an exemplary programinformation management table for administering program information.

The authentication information table shown in FIG. 15 is used toestablish authority to execute by means of combinations of user IDs andpasswords. The program information management table shown in FIG. 16 isused to define operations executable depending on the route by which aprogram is run and the authority to execute. For example, in the case of“User” authority to execute, regardless of the route by which a programis run, modification of resources of the storage device 20 will not bepermitted, with only reference to resources being permitted.

On the other hand, where “Administrator” authority to execute have beenestablished, in the event that the management program B has been run viathe management program A, modification of resources of the storagedevice 20 will be permitted, whereas if the management program B hasbeen run directly, only reference to resources of the storage device 20will be permitted. That is, in addition to authority to executedetermined on the basis of user ID and password, operations that willultimately be executable for resources of the storage device 20 aredetermined with reference to the route by which management program isrun.

(3) Whereas in the embodiments hereinabove, the invoking programexecuting module that executes the invoking program and the invoked[program] executing module that executes the invoked program arerealized by means of a single CPU 11, there could instead be provided anumber of CPUs, with the invoking program executing module and theinvoked program executing module being realized respectively by theCPUs.

(4) Whereas in the embodiments hereinabove, the management program (Pb)comprises cross-check information with the program ID (program runningroute) of the management program A (the invoking program), it would bepossible instead to prepare an interface in the management program A ona per-management program basis, with the management program A providinga program ID (program running route) depending on the interface.

(5) Whereas in Second embodiment, the authentication computer 60 sendsauthority to execute established with respect to the management programB (Pb2), it would be possible to make notification of whether executionof a request input from the client computer 30 is Allowed or NotAllowed, rather than of authority to execute. This has the advantagethat there is no need in the management program B (Pb2) for a table thatassociates authority to execute with executable operation processes.

(6) Whereas in the embodiments hereinabove, there were describedexamples in which several management programs are installed on a singleadministration computer 10, 100, the invention could be implementedanalogously in cases where a number of administration computers eachhaving a single management program installed thereon interact, toexecute processes requested by client computers.

(7) Whereas in the embodiments hereinabove, there were describedexamples of an administration computer for a storage device 20 making upa SAN, but implementation would be similar for NAS (Network AttachedStorage). In this case, the management processes and access restrictionsdescribed above could be executed by routing through a management portfor the NAS.

While the computer, access control method in a computer, and computersystem which pertain to the invention have been described hereinabove onthe basis of embodiments, the embodiments of the invention set forthherein are intended to aid in understanding of the invention, and shouldnot be construed as limiting. Various modifications and improvements tothe invention without departing from the spirit and scope thereof as setforth in the appended claims, and these equivalents will of course beencompassed in the invention.

1-17. (canceled)
 18. A computer for managing a first managed apparatus,the computer comprising a processor that executes programs stored in amemory; the memory comprises an integrated management program, anapparatus management program for the first managed apparatus, and usermanagement information; the computer is coupled to the first managedapparatus and is configured to: receive user authentication informationof a first user, and a management request for the first managedapparatus for at least the apparatus management program; wherein theuser management information indicates a first authority and a secondauthority for the first user, the first authority is an authority thatthe first user manages the first managed apparatus by using theapparatus management program without the integrated management program,the second authority is an authority that the first user manages thefirst managed apparatus by using the apparatus management programthrough the integrated management program; wherein if the userauthentication information and the management request are for theapparatus management program: the apparatus management program decideswhether the first user has an authority to execute the managementrequest based on the first authority of the user management informationand the user authentication information, and the apparatus managementprogram sends the management request to the first managed apparatus ifthe first authority includes permission to execute the managementrequest; wherein if the user authentication information and themanagement request are for the integrated management program: theintegrated management program decides whether the first user has anauthority to execute the management request based on the userauthentication information and based on the user management informationor another user management information for the integrated managementprogram, the integrated management program internally or externallysends a management request to the apparatus managed program with theuser authentication information if the first user is permitted toexecute the management request for the integrated management program,the apparatus management program decides whether the first user has anauthority to execute the management request based on the secondauthority of the user management information and the user authenticationinformation, and the apparatus management program sends the managementrequest to the first managed apparatus if the second authority includespermission to execute the management request; and wherein the firstauthority and the second authority are different.
 19. A computeraccording to claim 18, wherein the first authority includes permissionto refer to a first resource of the first managed apparatus, and thesecond authority includes permissions to refer and create the firstresource of the first managed apparatus.
 20. A computer according toclaim 18, wherein the user authentication information includes anidentification of the user.
 21. A computer according to claim 19,wherein the first managed apparatus is a storage apparatus, and theresource is a volume of the storage apparatus.
 22. A computer accordingto claim 18, wherein the computer is further configured to: receive userauthentication information of a first user, and a management request fora second managed apparatus for at least the apparatus managementprogram; and wherein if the user authentication information and themanagement request are for the apparatus management program, then theapparatus management program sends the management request to the secondmanaged apparatus if the first authority includes permission to executethe management request, and if the user authentication information andthe management request are for the integrated management program, thenthe apparatus management program sends the management request to thesecond managed apparatus if the second authority includes permission toexecute the management request.
 23. A management computer coupled to afirst managed apparatus over a computer network, the management computercomprising a processor that executes programs stored in a memory, themanagement computer is configured to: receive a management request anduser authentication information at the management computer from a clientcomputer for utilization of the first managed apparatus through at leastone of an apparatus management program at the management computer or anintegrated management program stored at the management computer;determine a first authority and a second authority for a first user atthe client computer, based on user management information stored at themanagement computer, wherein the first authority is an authority throughwhich the first user manages the first managed apparatus by using theapparatus management program without the integrated management program,and the second authority is an authority through which the first usermanages the first managed apparatus by using the apparatus managementprogram through the integrated management program; wherein if the userauthentication information and the management request are forutilization of the first managed apparatus through the apparatusmanagement program, then: the apparatus management program decideswhether the first user has an authority to execute the managementrequest based on the first authority of the user management informationand the user authentication information, and the apparatus managementprogram sends the management request to the first managed apparatus ifthe first authority includes permission to execute the managementrequest; wherein if the user authentication information and themanagement request are for utilization of the first managed apparatusthrough the integrated management program, then the integratedmanagement program: decides whether the first user has an authority toexecute the management request based on the user authenticationinformation and based on the user management information or another usermanagement information for the integrated management program, internallyor externally sends a management request to the apparatus managedprogram with the user authentication information if the first userpermitted to execute the management request for the integratedmanagement program, decides whether the first user has an authority toexecute the management request based on the second authority of the usermanagement information and the user authentication information, andsends the management request to the first managed apparatus if thesecond authority includes permission to execute the management request;and wherein the first authority and the second authority are different.24. A management computer according to claim 23, further configured to:receive a management request and user authentication information at themanagement computer from the client computer for utilization of a secondmanaged apparatus through at least one of an apparatus managementprogram at the management computer or an integrated management programstored at the management computer; wherein if the user authenticationinformation and the management request are for the apparatus managementprogram, then the apparatus management program sends the managementrequest to the second managed apparatus if the first authority includespermission to execute the management request, and if the userauthentication information and the management request are for theintegrated management program, then the apparatus management programsends the management request to the second managed apparatus if thesecond authority includes permission to execute the management request.